Adds CurrentUser processor #16
Conversation
|
@dlindahl: Derek, is this still an issue? |
|
Yes, it is. I've realized that there is no way to easily get the current user, but I am about 75% done with a PR to add that support. I'd like to keep this open so that I can convert it into a Pull Request once I am done, if thats OK with you. |
|
Sounds good! |
Rails declares ActionController::Base#cookies to be a private method. CASino should respect this and not change it to be public just so that listeners can interact with them. This adds a convenience method to CASino::Listener that exposes an API into ActionController::Base#cookies by calling #send in order to access the private method.
|
This extracts the "find user by TGT" logic that exists in all of the processors and puts it in a CurrentUser processor. This processor is automatically run in a :before_filter for most controller actions. If a user is found, then the User record is assigned to the An additional benefit of this feature is that the host application can also use this value in its own views: # In my_app/app/controllers/widgets_controller.rb
class WidgetsController < ApplicationController
include CASino::CurrentUserHelper
def index
# ...
end
end
# In my_app/app/views/widgets/index.html.erb
<div class="widgets">
<% if user_signed_in? %>
<%= debug current_user %>
<% end %>
</div>
|
| end | ||
|
|
||
| def user_signed_in? | ||
| current_user |
There was a problem hiding this comment.
Should be !!current_user to always return a boolean.
This extracts the "find user by TGT" logic that exists in all of the processors
and puts it in a CurrentUser processor.
This processor is automatically run in a :before_filter for most controller
actions. If a user is found, then the User record is assigned to the
@current_user instance variable. From there it can be passed into the other
processors as well as be used in the various CASino views.
An additional benefit of this feature is that the host application can also
use this value in its own views:
```ruby
class WidgetsController < ApplicationController
include CASino::CurrentUserHelper
def index
# ...
end
end
<div class="widgets">
<% if user_signed_in? %>
<%= debug current_user %>
<% end %>
</div>
```
* Adds CurrentUser processor to encapsulate all user look-up based on TGT
values
* Provides #current_user and #user_signed_in? controller helper methods
* Refactored some more complicated internal logic out into private methods
for a handful of processors
|
@pencil, what's up here? |
|
Okay, so i'll just keep it open 😄 |
|
I think we should plan a major overhaul of the processor/listener approach we currently use. It's too complicated and not of much use since we merged CASino and CASinoCore. |
|
CASino 4.0 will feature an easy way to access the desired information. (#63) |
I'd like to add a few additional pages to my CASino powered application that require a user to be signed in.
Most authentication systems provide a
user_signed_in?method to determine if a user is currently signed in and/or acurrent_userthat returns that user's record. These methods are also typically used in abefore_filterto restrict access to sensitive pages.Browsing through the source code, it does not appear that there are any controller helpers that provide this information. The closest thing I could find was in
app/controllers/casino/sessions_controller.rbon lines 5-6However, I'm not sure that these methods would work very well in a helper method if they were simply ported over.
Do you have any thoughts on how to expose this information to application controllers outside of the context of CASino itself?